Identity Management in Internet of Things with Blockchain

219

identity validators. Therefore, the single point of failure threat is removed, since

client applications don’t need to connect to the exact same service neither for issuing

or modifying the identity nor for validating themselves when using resources.

3.1.2

Logic: Authorization Policies—Smart Contracts

Every IAM model is designed in order to keep hold of an environment-specific and

hierarchic model, regarding who has the right to do what, or the logic of the IAM

system. These, in a centralized system, are called policies and are implemented using

an authorization framework (e.g., OAuth [20]). Blockchain can natively implement

these policies using smart contracts, which are, essentially, code accessed by all the

network nodes, or at least for those validating an entity. This way, the policies can be

inspected by any node in the network while the validation process is open and can

happen randomly throughout the network, eliminating the possibility of malevolently

influencing one node to gain access.

3.1.3

Logic: Identity—Decentralized Identity

The identity component is the one holding the information of each entity in the

system. All kinds of attributes that characterize each entity and its role in the system

are contained to its identity. In the traditional centralized systems, entities (whether

users or devices) do not hold their own identities. The identity provider holds all iden-

tities, and any entity asking access to a resource invokes their identity by providing

their unique credentials (e.g., username, password).

A decentralized identity is a key component that revolutionizes the whole decen-

tralized IAM architecture. It is comprised of the cryptographic information derived

from the entity’s unique properties, while it also contains its attributes. The main

difference between the centralized identity and the decentralized one is that in the

latter, each entity is the owner and the holder of their identity. Consequently, in that

case, it must also be defined who can modify which attributes. An entity should

have the right to modify some of the attributes of their identity (e.g., username),

while some others (e.g., level of access) should be changed only by an identity issuer

according to the rules specified in smart contracts. Another main difference is that

since the identity is now stored locally and not at a central storage available to the

whole network, then the attributes composing it can be aggregated by multiple issuers

(technically multiple IdPs) [21]. In this context, a decentralized identity can also be

the result of many issuing processes by many IdPs asserting multiple roles for the

respective entity.